June 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 305592] Warn on creating of the package that already exists in BuildService
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305592, revision 1, last change by Title: Warn on creating of the package that already exists in BuildService Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html * warn on creating of the package that already exists in BuildService (webclient and osc) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305592

1 3

[openFate 305590] Virtual packages and virtual joint projects
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305590, revision 1, last change by Title: Virtual packages and virtual joint projects Buildservice: New Priority Requester: Desirable Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00094.html Virtual packages and virtual joint project would be a special type of projects, that are part of a standard binary repository, but they have no source present in the project. It may have several typical use cases: Virtual dependency packages --------------------------- When a project intents to update a library to a newer version, virtual dependency packages and projects may determine packages that will have broken/changed dependencies after installing of a new library. How it should look. Either package or a project should have a new attribute: "Rebuild parent project packages" Possible values: "ignore": Rebuild only packages in this project and nothing else (just the current behavior) "rebuild broken": Rebuild parent project packages, that cannot be used with newer version any more (it typically happens for package, that require exact version it is built against, or packages that don't follow shared library packaging conventions) "smart rebuild": Rebuild packages that require package or symbol that are no more part of the output of the new package. "all dependencies": Behave just like a single repository and rebuild everything which uses the new in the build. Examples of use for particular values: "rebuild broken": Building some modules require the same version of the base package it was build with. When trying to update base package in a project, it will rebuild all such modules. "smart rebuild": Testing package poppler update: New poppler has a new soname and it requires to rebuild all packages that are linked with poppler. However it is possible to install these packages (and use shared library from the parent project), testing of the new library requires to rebuild these package with the new library). "all dependencies": Testing new core package (bison, gcc). All packages, that have this package in BuildRequires on build system will be rebuilt. Virtual package may become non-virtual. If you need to patch one of the packages to be able to rebuild it in the new repository, you have to link it physically to the joint repository. In this moment, package becomes equal to the normal link package, disabled by default. Virtual/non-virtual joint project --------------------------------- Just now, one can include two different projects, that have a disjunctive packages. Virtual joint project would determine packages that will build differently (or break) in one or another parent repository and rebuild them as a separate repository. Virtual joint project could be a separate project that contains rebuilds of packages in the intersection of both project. Virtual joint project may become non-virtual. If you need to patch one of the packages to be able to rebuild it with both projects included, you have to add it physically to the joint repository. In this moment, the joint project feature would be equal to the normal repository with "Rebuild parent project packages" set. Example: Suppose you have a testing repository of new poppler (different soname) and a multimedia:photo with a new version of GIMP (requires poppler). You can easily include both multimedia:photo and poppler test repositories, but you cannot test new gimp with a new poppler. Creating of virtual joint project will automatically detect these packages and rebuild them. There could be again the tag "Rebuild parent projects packages" with the same values as above. Benefits: Virtual packages: Now they are often substituted by links. Several years later, nobody knows, why such link was created and the link may rot there forever. Virtual joint project: It will allow to test result of a dangerous package check-in without actually doing it. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305590

1 3

[openFate 305595] Show dependencies between packages in repo
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305595, revision 1, last change by Title: Show dependencies between packages in repo Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: * Show dependencies (Requires, BuildRequires) between packages in repository OBS should provide lists of required packages (runtime and build dependencies) - BuildRequires could be extracted from spec files - it is important to show also reverse dependencies (eg. which packages depend on the package I'm maintaining) - Requires are much harder (will probably need also symbol resolution), but not so desperately needed as BuildRequires -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305595

1 4

[openFATE 305937] Delete Request Mechanism
by fate_noreply＠suse.de 19 Feb '10

19 Feb '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #305937, revision 1, last change by Title: Delete Request Mechanism Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Description: As part of our PDB migration, we need a mechanism to request a package removal in a project, where no write access exists. Klaas, can you make a proposal how a package (and project ?) removal can look alike ? -- openSUSE Feature: https://features.opensuse.org/305937

1 3

[openFATE 306006] btrfs in openSUSE
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Marek Stopka (m4r3k) Feature #306006, revision 1, last change by Title: btrfs in openSUSE openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Marek Stopka (m4r3k) Description: I think it is time to make btrfs as a part of upcoming openSUSE 11.2, probably with BIG warning but still there should be possibility to use btrfs and even better with some kind of integration in YaST disk module... Fedora is going for btrfs with next release either. -- openSUSE Feature: https://features.opensuse.org/306006

1 12

[openFATE 306529] Deactivate build if home:user:branch:foo is inactive for 1 or 2 weeks
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Jan-Simon Möller (dl9pf) Feature #306529, revision 1 Title: Deactivate build if home:user:branch:foo is inactive for 1 or 2 weeks Buildservice: Unconfirmed Priority Requester: Important Requested by: Jan-Simon Möller (dl9pf) Description: It would save quite some cpu-cycles if branches which are not in active use - e.g. no change in 1 or 2 weeks - would just get the build disabled. Thus the wave during each factory checkin wouldn't be that high. Or even delete branches if they're inactive for 1 or 2 weeks and only the pristine _link is there. This could be extended to disable the build for factory repos in user's home-dir if there're no checkin's for some time. I don't want to prevent ppl from tracking factory in their home: , but a plain _link is just pointless and build should be disabled automagically after some time. -- openSUSE Feature: https://features.opensuse.org/306529

1 3

[openFATE 306426] Add Package Wishlist
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Klaas Freitag (kfreitag) Feature #306426, revision 1, last change by Title: Add Package Wishlist Buildservice: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Description: In the Buildservice, the package wishlist should be accessible. That would make it easy to pick packages and build it if bored. -- openSUSE Feature: https://features.opensuse.org/306426

1 5

[openFATE 306589] Improve help for CA Management
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature added by: Michael Calmer (mcalmer) Feature #306589, revision 1 Title: Improve help for CA Management openSUSE-11.2: New Priority Requester: Desirable Requested by: Michael Calmer (mcalmer) Description: This Module should offer a Hyperlink to far more text - possible online. Relations: - CA Management Module has Virtually No Help (novell/bugzilla/id: 515863) https://bugzilla.novell.com/show_bug.cgi?id=515863 -- openSUSE Feature: https://features.opensuse.org/306589

1 2

[openFATE 306590] Yast Common Server Certificate should support modify, delete, export
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature added by: Michael Calmer (mcalmer) Feature #306590, revision 1 Title: Yast Common Server Certificate should support modify, delete, export openSUSE-11.2: New Priority Requester: Desirable Requested by: Michael Calmer (mcalmer) Description: More features for Common Server Certificate requested: * Ability to Modify/change the certificate * Ability to Delete * Ability to Export Relations: - Yast Common Server Certificate (novell/bugzilla/id: 510798) https://bugzilla.novell.com/show_bug.cgi?id=510798 -- openSUSE Feature: https://features.opensuse.org/306590

1 3

[openFATE 306007] Ship more vanilla
by fate_noreply＠suse.de 12 Dec '09

12 Dec '09

Feature added by: Klaas Freitag (kfreitag) Feature #306007, revision 1, last change by Title: Ship more vanilla openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Description: Upstream projects such as KDE 4 often are developed with very high care for usability, design and eye candy, staffed with high skilled specialists and/or artists. openSUSE modifications against the vanilla versions sometimes do not really improve the upstream version. Moreover, these kind of modifications often kind of rebrand the projects, for example by replacing the KDE startmenu button by an openSUSE branded one. The openSUSE distribution as a community project should maintain the brand of the upstream projects and not hide them from the distributions users. Also patching vanilla behaviors where not technically needed or fixing problems should be handled very carefully and only happen in good dialog with upstream. -- openSUSE Feature: https://features.opensuse.org/306007

1 11