How to register distros?

Asked by Jeff Johnson

I'm trying to use Launchpad as an uber-bug tracker/aggregator for RPM.

That's working just fine for major linux distros. I can attach a bug in
an external tracker to a major distro.

However, there are several minor linux distros that I need to aggregate bugs from:
   unity http://unity-linux.org/
   yoper http://yoper-linux.org/
   idms http://idms-linux.org/tiki-index.php
   ark http://www.arklinux.org/
   caixa http://www.caixamagica.pt/pag/a_index.php

And then there are major non-linux distros where I would like to aggregate bugs from:
   macports (LP already has http://trac.macports.org/ registered)
   freebsd

Could/should these distros be registered somehow please?

Alternatively, an "other" distro category should/could be added too (but I'd
rather tracke RPM bugs specific to distros somehow).

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Jeff Johnson
Solved:
Last query:
Last reply:
Revision history for this message
Jeff Johnson (n3npq) said :
#1

Please add another minor non-linux distro too:
   openpkg http://www.openpkg.org/

Revision history for this message
Curtis Hovey (sinzui) said :
#2

I do not think we should do this because Launchpad is not effective at tracking bugs in non-Debian based distros. It is not possible to register a bug tracker for a distro so enabling bug tracking does not allow correct reporting of where the bugs are tracked.

I think it was a mistake to add Fedora and Gentoo because it is not possible to match source package names: ack != ack-grep != text/ack. When you see bugs where users have reported that a bug also affect a non-Debian distro, the source package is not mapped properly. Launchpad has no way to verify a package was published in a non-Debian distro; it is impossible to say what version has the bug.

I think we need to understand what you want to aggregate. You could register a project and bug tracker each distro, but I am not certain that solves your problem.

Revision history for this message
Jeff Johnson (n3npq) said :
#3

Understood.

I'm attempting to track "upstream RPM" bugs. Many bugs are being reported
(some more >5 years old, see recent CVE's repeated against RPM in June)
so that information/patches start to flow between vendors and distros.

(aside)
re "mistake": I was @redhat when bugzilla was first set up in 1998. The 1-to-many
relationship between source <-> binary packages is arguably a similar "mistake".
And when naming then starts mapping, say, "RPM" across forks (rpm5.org <-> rpm.org),
and across distros (fedora <-> mandriva) and across OS (linux <-> MacOSX), well
version is essentially meaningless as an identifier.

I can easily appreciate the difficulties presented by adding Fedora/Gentoo at Launchpad.

But if you want this users feedback:

    w00t! I have succeeded in tying MULTIPLE distros together into an umbrella bug! Here's
    an example of my usage case (the context is a fundamental design bug that is present in RPM
    for like 10 years that was identified last November.)
        https://bugs.launchpad.net/rpm/+bug/633208
    I've been avoiding the labor intensive coordination with all the distros (and
    all RPM based distros) solely because its gonna take years of patient effort
    to communicate the essential details, and hand a patch to all the distros
    using RPM (whether distros choose to use the patch, or LP, or anything else
    is a very different question; I have a duty and obligation to make the patch
    exist with sufficient information that will permit informed choice).

But the bugs are the common elements that I am trying to track.

And a project tied to a bug tracker is all I really need.

N00b question: Should I just add projects (and claim that I do not wish to maintain)
for these other distros? I can do that ... but *please* make a suggestion if you
have serious reservations about fedora/gentoo "mistakes".

I most definitely and more interested in supportable/maintainable infrastructure.
I can always do something else instead.

Revision history for this message
Jeff Johnson (n3npq) said :
#4

Perhaps I should also offer some positive assistance ...

I know just about everything there is to know about RPM. And I am
well connected with many RPM based distros, having been the
sole developer of RPM for way too long @redhat.com.

I have also been involved with "LSB packaging" since before LANANA
(the package name registry invented by LSB) was proposed.

Would you LIKE to track *.rpm packages into distros at Launchpad?

I'll be happy to help ... in fact I am actively working on prototyping
a distributed NoSQL! store using mongo or Cassandra or Berkeley DB
to track packages into repositories based on distros.

Revision history for this message
Curtis Hovey (sinzui) said :
#5

There are many distros registered as projects because the users wanted to register a bug tracker or a some other aspect. I think it is fine to register these distros as project so that we can track upstream bugs. It is also fine to disclaim ownership. The project in that case will be maintained by the Registry Admins. We are happy to update these project on user request--one day I will solve the permission problem so that any Lp user can update a registry admin project.

I remain concerned about the package name problem, You will only be able to report bugs against packages that match the names of Debian/Ubuntu's packages. This may not be an issue. You can register bug trackers for each distro separately. Though the bug tracker and distro are not connected, you can still set bug watches. All other pages for the distro will not work. I can ask an Admin to register a distro. he will need the display name, summary, description, and domain name.

Revision history for this message
Jeff Johnson (n3npq) said :
#6

I'm comfortable with the restrictions stated and will work around (or possibly abandon the
goal of a uber-bugtracker for rpm) if any issues are encountered.

And if there is anything I can do to help with the package naming concerns, just ask. It is indeed a
complex problem attempting a name space. Luckily most packages have
obvious names identical to Debian/Ubuntu. Except for "rpm" but that's a whole
different class of problem, sigh.

Thanks for info and help

Revision history for this message
Jeff Johnson (n3npq) said :
#7

FYI re reservations act package naming in comment #2

This talk at FOSDEM/2012 starts to address naming divergence for
packages in multiple distros:
    http://fosdem.org/2012/schedule/event/distromatch

Its basically a similarity metric based on package content that
determines the most similar package based on content.

The naming divergence for packages in linux distros is
still a very challenging problem.